Remarks 

Status of application 

Claims 1-48 were examined and stand rejected in view of prior art and for 
technical reasons. Applicant has amended claims 1, 21 and 36 to address the rejection of 
Applicant's claims under 35 U.S.C. Section 1 12. In view of the amendments made and 
the following remarks, reexamination and reconsideration are respectfully requested. 

The invention 

For a concise statement of Applicant's invention, please refer to the Summary of 
Invention in Applicant's previously filed Appeal Brief. 

General 

A. Section 1 12 rejection 

The Examiner has rejected Applicant's claims under 35 U.S.C. 1 12, second 
paragraph as indefinite as the Examiner states that it is unclear how the components are 
working together. Applicant respectfully believes that its claims are clearly structured as 
computer-implemented systems and methods; however, Applicant has amended 
independent claims 1,21 and 36 in order to overcome the Examiner's rejection. 

Prior art rejections 
A. General 

This Amendment is filed in response to the fourth Office Action in this case. In 
this most recent Office Action, the Examiner has rejected Applicant's claimed invention 
under Section 103 based on 8 different combinations of 1 1 different prior art references. 
As noted in Applicant's previously filed Appeal Brief in this case, while there is no 
absolute cap or ceiling as to the number of references that may form a competent 
combination under Section 103, the fact that the Examiner is having to go to this sizeable 
collection of 1 1 different references to string together eight different "obviousness" 
rejections again begs the question what exactly is "obvious." At some point, the thread of 
logic used to weave together such a large number of references becomes stretched so thin 
that it breaks. Applicant respectfully submits that this is the case here and that the large 
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disparate and large collection of art and numerous combinations of references used in this 
case indicates that the rejection does not establish obviousness under Section 103. 

Additionally, in the most recent office action the Examiner relies largely U.S. 
Published Application No. 2002/0065752 Al of Lewis (hereinafter "Lewis") in rejecting 
Applicant's claimed invention. However, as discussed below in more detail, in a prior 
Office Action the Examiner previously withdrew Lewis and issued new grounds of 
rejection, which would also appear to call into question the seven grounds of rejection 
that rely on Lewis. Additionally, the Examiner's continued reliance on Cohen in the 
rejection of claims 27, 42, 33 and 47 despite withdrawing Cohen from the rejection of all 
of Applicant's other claims also appears somewhat puzzling. 

B. First Section 103 rejection: Lewis, Suzuki and Thompson 
Applicant's claims 1-2, 4-9, 18-22, 24, 28-31, 33-37, 39, 43-46 and 48 stand 
rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. Published Application 
No. 2002/0065752 Al of Lewis (hereinafter "Lewis") in view of US Published 
Application No. 2002/0072922 Al of Suzuki et al. (hereinafter "Suzuki") and further in 
view of U.S. Patent 6,668,253 of Thompson et al. (hereinafter "Thompson"). 

In the most recent Office Action, the Examiner again relies largely on Lewis in 
rejecting Applicant's claims, despite the fact that the Examiner previously withdrew the 
same Lewis reference (and reopened prosecution based on a new ground of rejection) in 
response to Applicant's previously filed Appeal Brief in this case. Here, it should be 
noted that the Lewis patent (U.S. Patent No. 7,310,615 issued December 18, 2007) cited 
by the Examiner in the first two Office Actions in this case is a continuation of the 2002 
Published Application cited by the Examiner in the most recent Office Action 
(Application No. 2002/0065752 Al of Lewis which was issued as U.S. Pat. No. 
6,513,019). Therefore, Applicant believes that Lewis is clearly distinguishable for the 
reasons discussed in detail in Applicant's Appeal Brief previously filed in this case on 
December 9, 2008 (and incorporated herein by reference). The Examiner's reopening of 
prosecution and issuance of new grounds of rejection (e.g., that Applicant's claimed 
invention was anticipated by U.S. Published Application No. 2003/0097331 A of Cohen) 
in the Office Action dated March 18, 2009 in response to Applicant's Appeal Brief 
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certainly seems to indicate that (at least at that time) the Examiner agreed with 
Applicant's argument that Lewis was clearly distinguishable. However, the Examiner has 
now largely abandoned Cohen and has returned to reliance upon Lewis in rejecting 44 of 
Applicant's 48 pending claims. Applicant respectfully requests that the Examiner clarify 
his position as to why the rejection based on Lewis was withdrawn in an earlier Office 
Action and then subsequently reinstated as Applicant continues to believe that Lewis (as 
well as the secondary Suzuki and Thompson references) are distinguishable in several 
respects, including those discussed below as well as those indicated in Applicant's 
previously filed Appeal Brief. 

Lewis describes a consolidation system that stores all records derived from each 
of the sources, including both real-time and file-based sources. In doing so, Lewis 
duplicates considerable data as it stores records from live data during the business day as 
well as file-based transaction data, which are typically received after the end of the 
business day . Applicant's invention, in contrast, recognizes that today's real-time 
transactions are tonight's file-based transactions and therefore the two sets of sources 
include large quantities of duplicate data. Applicant's solution operates to eliminate this 
duplicate data by replacing real-time transaction data with the officially posted 
transaction data when the official transaction data is available (e.g., at the end of the day). 
This feature is also included, for instance, in the claim limitations of Applicant's claim 1 
as follows: 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records , assigning a unique 
identifier to each consolidated transaction record for an account, and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
system that is duplicated in said parsed information from the data files 

(Applicant's claim 1, emphasis added) 

This feature of removing duplicate transaction information during the consolidation 
process reduces the quantity of the data that is maintained by Applicant's solution, 
provides increased consistency and improves performance. 

The Examiner references Lewis at paragraph [0123] as providing the 
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corresponding teachings. However, the referenced portion of Lewis reads as follows: 

The Validation Process ensures the accuracy of the data and prevents duplicative 
entries. The Validation Process applies quality assurance rules, pre-defined by the 
user, to the incoming data. The data is compared against pre-existing records to 
discern any discrepancies, and to test for changes in excess of acceptable 
tolerances. Missing data is calculated or derived from other data, where possible. 
Errors and omissions trigger notifications, via the notification server, to the 
appropriate staff, who can then correct the data using a desktop application. Once 
completed, the Validation Process presents the enriched information to the 
Construction Process. 

(Lewis, paragraph [0123]) 

Respectfully, Lewis simply mentions that a "Validation Process" may be used to prevent 
duplicate entries in incoming data without providing any further detail about what this 
Validation Process might entail. Thus, it is unclear to one having ordinary skill in the art 
what Lewis' Validation Process might entail or how it is implemented. In particular, 
Lewis makes no mention that the process may include removing transaction information 
derived from a user accessible system that is duplicated in parsed information extracted 
from incoming data files in creating consolidated transaction records as provided, for 
example, as specific claim limitations of Applicant's claim 1 . Additionally, Lewis' 
system is handling market data and not transaction data and therefore whatever validation 
steps are applied are likely to be quite different than those utilized by Applicant's solution 
which is specifically focused on consolidation of transaction records. 

The Examiner also acknowledges that the primary Lewis reference does not 
include teachings of representing additional information present in a data file being 
processed in Extensible Markup Language (XML) format and therefore adds Suzuki as 
providing such teachings. However, Suzuki's solution is focused on collecting and 
displaying content in an Internet web portal and its teachings are distinguishable from 
Applicant's claimed invention for the reasons discussed below. 

Applicant's claimed invention addresses one of the complications in processing 
records from different financial institutions in that different institutions frequently 
customize or extend the standard file format (e.g., BAD to capture additional information . 
Applicant's solution operates to identify, capture and sort this extra information that is not 
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defined as a standard data element of the standard file format (e.g., BAI file format). In 
this regard, Applicant's solution acts to capture and store "standard" information in 
columns and rows of a database and to also capture and store "extra" information in XML 
format (see e.g., Applicant's specification, paragraphs [0066]-[0067]). Suzuki, in 
contrast, does not operate to process incoming data files . Instead, Suzuki's solution 
operates to display content to clients in a web portal based on stored data obtained from 
an "information disclosing server" (see e.g., Suzuki, paragraph [0048] and Fig. 1 (client 
5, portal server 3 and information disclosing server 1)). Thus, Suzuki does not describe 
extracting data from input files, but rather describes constructing content for display from 
previously stored information . For example, Suzuki describes that the information 
disclosing server includes "...contents storing means la and additional information 
storing means lb." (Suzuki, paragraph [0049]). Suzuki's contents storing means la 
"stores" contents consisting of information, services, or the like and the additional 
information storing means lb stores additional information indicating the attributes of 
contents to be disclosed (see e.g., Suzuki, paragraphs [0050]-[0051]). 

It should be noted that Suzuki provides no teaching or suggestion of a file 
importer for processing incoming data files (e.g., BAI data files) containing additional (or 
extended) data fields and storing this additional information in XML format. Instead, 
Suzuki's system is focused on retrieving and displaying previously stored content. As 
such its teachings do not appear to be at all analogous to Applicant's claimed invention. 

Additionally, Applicant's solution not only handles transaction data that is 
received via a file, but also handles transaction data received from a live, user-accessible 
system (see e.g., Applicant's specification, paragraphs [0071]-[0072]). In this case, 
transaction data arrives via a programming object and is converted from object (e.g., 
HashMap) format to XML format. Thus, Applicant's claimed invention supports both 
file-based and object-based transactions with the same underlying mechanism and 
handles both "standard" data as well as custom or "extra" information. When transaction 
data from file or live sources is found to contain "extra" information, Applicant's solution 
converts this extra information to XML format for storage. Respectfully, no similar 
teachings or suggestions are found in Suzuki or the other cited prior art references (i.e., 
Lewis and Thompson). In fact, the solution described by Lewis uses generated C++ 
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objects to represent a particular piece of data. As such, data that contains extra/custom 
properties cannot be supported in Lewis' system. Additionally, although Suzuki mentions 
storing attributes (additional properties) in XML format, there is still a gap between 
Lewis' C++ object and the XML data representation of the object. Because Lewis' 
system generates C++ objects, the fields have to be known up front. With Applicant's 
solution, in contrast, the fields do not need to be known up front, do not need to be the 
same for each record, and can dynamically change without changes to the system. 

The Examiner also acknowledges that Lewis does not disclose a reporting module 
for presenting consolidated financial transaction information for a particular account and 
allowing the user to navigate through the consolidated information and therefore adds 
Thompson as providing such teachings. However, Applicant's review of Thompson finds 
no mention whatsoever of assigning a sequence number or other unique identifier to each 
transaction record . Although a key word search of Thompson will find that Thompson 
does use the word "identifier", the identifier referred to by Thompson is a "valid user 
identifier and password" which the user must enter in order to access the system. 
Respectfully, this is not comparable to the unique identifier of Applicant's claimed 
invention that is associated with transaction records. 

Applicant's solution includes reporting features that provide for ordering the 
transaction information and assigning a unique identifier (e.g., sequence number) to each 
transaction stored in the repository (see e.g., Applicant's specification, paragraph [0069]). 
This unique identifier facilitates paging the transaction information to the user in 
manageable groups or "chunks" of information, such as in groups of ten transactions 
organized based on sequence number (see e.g., Applicant's specification, paragraphs 
[0069]-[0070]). The user may, for example, then navigate through the transactions in 
sequence. This feature is also included as limitations of Applicant's claims. For 
example, Applicant's claim 1 includes the following claim limitations: 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records, assigning a unique 
identifier to each consolidated transaction record for an account , and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
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system that is duplicated in said parsed information from the data files; and 
a reporting module for receiving a request for financial transaction information 
for a particular account and presenting consolidated transaction records for the 
particular account to the user in response to the request, wherein the user may 
navigate through said consolidated transaction records based upon said unique 
identifier . 

(Applicant's claim 1, emphasis added) 

In contrast to these specific features of Applicant's claimed invention, Thompson makes 
no mention of a unique identifier assigned to each transaction record. As Thompson does 
not utilize a unique identifier for each transaction record, Thompson obviously cannot 
teach or suggest using such identifier to facilitate display of the information to the user as 
with Applicant's claimed invention. 

All told, the combined references do not include teachings of a consolidation 
system that consolidates real-time transaction data from a live system with file-based 
transaction data and removes duplicate data in the process of consolidating data from 
different sources. Additionally, none of the cited prior art references include any 
teaching or suggestion of converting additional data fields in input data files into XML 
format during processing of input data files. The combined references also include no 
teaching or suggestion of assigning a unique identifier to each transaction and using this 
identifier to assist the user in navigating through transaction data. Therefore, as the 
Lewis, Suzuki and Thompson references, even when combined, do not include all the 
limitations of Applicant's claims it is respectfully submitted that Applicant's claims 
distinguish over the prior art and overcome any rejection under Section 103. 

C. Second Section 103 Rejection: Lewis, Suzuki, Thompson and Campbell 
Claims 3, 23 and 38 stand rejected under 35 U.S. C. 103(a) as being unpatentable 
over Lewis (above) in view of Suzuki (above) in view of Thompson (above) and further 
in view of U.S. Patent 6,856,970 of Campbell et al (hereinafter "Campbell"). As to these 
claims, the Examiner acknowledges that Lewis, Suzuki and Thompson fail to teach at 
least one file adapter for extracting data from a particular type of data file, such as a BAI 
file. Therefore, the Examiner adds Campbell as providing these teachings. 

Applicant's claims are believed to be allowable for at least the reasons cited above 
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(as to the first Section 103 rejection) pertaining to the deficiencies of Lewis, Suzuki and 
Thompson as to Applicant's invention. Campbell does not cure any of these deficiencies. 
Although Campbell describes a BAI format mapper which accounts for different 
interpretations of BAI used at different banks, it does not include any teaching of a 
system that consolidates real-time transaction data with file-based transaction data 
comparable to Applicant's claimed invention. Accordingly, as the combined references 
do not include all the limitations of Applicant's claims it is respectfully submitted that 
Applicant's claims distinguish over the combined references and overcome any rejection 
under Section 103. 

D. Third Section 103 Rejection: Lewis, Suzuki, Thompson and Hopkins 
Claims 10-12, 25 and 40 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lewis (above) in view of Suzuki (above), in view of Thompson 
(above) and further in view of U.S. Published Application 2005/0172137 of Hopkins et al 
(hereinafter "Hopkins"). Applicant's claims arc believed to be allowable for at least the 
reasons discussed in detail above pertaining to the deficiencies of Lewis, Suzuki and 
Thompson as to Applicant's invention, none of which are cured by Hopkins. Applicant 
also believes these dependent claims are allowable for the additional reasons discussed 
below. 

As discussed previously, Applicant's solution provides for assigning a unique 
identifier to each transaction stored in the repository to facilitate paging the transaction 
information to the user in manageable groups or "chunks" of information. Applicant's 
claim 10, for instance, adds that the unique identifier comprises a sequence number. 
Claim 1 1 adds that the sequence number is assigned per account and per type of 
transaction. Additionally, claim 12 provides that consecutive sequence numbers are 
assigned to transactions records of a given type for a particular account. Although 
Hopkins discusses sequence numbers, it assigns sequence numbers based on the 
particular terminal at which the transaction originates (Hopkins, paragraph [0025]). 
Thus, assuming the terminal that is involved in Hopkins' solution is a particular ATM, 
Hopkins unique identifier identifies the ATM and issues consecutive sequence numbers 
for transactions at that ATM. This is not the same as assigning sequence numbers "per 
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account and type of transaction" as provided by Applicant's claimed invention as 
discussed in greater detail in the Appeal Brief previously filed by Applicant in this case. 

Accordingly, as the combined references do not include all the limitations of 
Applicant's claims it is respectfully submitted that Applicant's claims distinguish over the 
combined references and overcome any rejection under Section 103. 

E. Fourth Section 103 Rejection: Lewis, Suzuki, Thompson, Hopkins and 
Ferlauto 

Claims 13-14, 26 and 41 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lewis (above) in view of Suzuki (above) in view of Thompson (above) 
in view of Hopkins (above) and further in view of U.S. Patent 6,895,926 of Ferlauto et al 
(hereinafter "Ferlauto"). Again, these claims are believed to be allowable for the reasons 
discussed in detail as to the above-described deficiencies of Lewis, Suzuki, Thompson 
and Hopkins as to Applicant's claimed invention, none of which are cured by Ferlauto. 
Ferlauto describes an address consolidating system including a name and address 
database in which duplicate names and address are consolidated by matching name and 
address and e-mail address simultaneously (Ferlauto, Abstract). As Applicant's claimed 
invention relates to consolidation of financial transaction records, Ferlauto's system for 
consolidation of name and address data appears only marginally relevant. 

Applicant also believes that Ferlauto does not teach or suggest the specific 
limitations of Applicant's dependent claims 13-14, 26 and 41 as discussed in detail in a 
prior Amendment filed in this case. Although Ferlauto describes several different kinds 
of sequences, Ferlauto's general approach is for the sequence numbers to go up by one for 
each subsequent record (see e.g., Ferlauto col. 2, line 65 to col. 3, line 6). Ferlauto also 
describes a separate "transaction date field" (YYYMMDD) which is based on the date the 
transaction is generated by the file owner (see e.g., Ferlauto, col. 3, lines 6-9). However, 
this date field is described as being separate from the sequence number and Applicant's 
review of the reference finds no mention of providing for the user to select between date- 
based and consecutive sequencing as provided with Applicant's claimed invention. Thus, 
as the combined references do not include all the teachings of Applicant's claims, 
Applicant respectfully submits that its claimed invention distinguishes over these 
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references. 



F. Fifth Section 103 Rejection: Lewis, Suzuki, Thompson and Battat 
Claim 15 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 

Lewis (above) in view of Suzuki (above) in view of Thompson (above) and further in 
view of U.S. Published Application 2006/0143239 of Battat et al (hereinafter "Battat"). 
Claim 15 is believed to be allowable for the reasons discussed in detail as to the 
deficiencies of Lewis, Suzuki and Thompson as to Applicant's claimed solution for 
consolidation of financial transaction records. Battat does not cure any of these 
deficiencies as Battat simply describes a method and apparatus for maintaining data 
integrity across distributed computer database systems. Additionally, Applicant 
respectfully believes that Battat's teachings of a commit operation which collapses all the 
operations in a given transaction into one undo-able operation are not comparable to 
Applicant's claim limitations of a data consolidator that provides for undoing transaction 
records created from a particular file in response to a user request to undo a particular 
file. Accordingly, as the combined references do not include all the teachings of 
Applicant's claims, Applicant respectfully submits that its claimed invention overcomes 
the Section 103 rejection. 

G. Sixth Section 103 Rejection: Lewis, Suzuki, Thompson, Battat and Smith 
Claims 16 and 17 stand rejected under 35 U.S.C. 103(a) as being unpatentable 

over Lewis (above) in view of Suzuki (above) in view of Thompson (above) in view of 
Battat (above) and further in view of U.S. Published Application 2002/0042975 of Smith 
(hereinafter "Smith"). Claims 16 and 17 are dependent on claims 1 and 15 and are, 
therefore, believed to be allowable for the reasons set forth above as to the deficiencies of 
Lewis, Suzuki, Thompson and Battat as to these independent and intervening claims. 
Smith does cure any of these deficiencies. Additionally while Smith describes 
identifying dependent files, Smith makes no mention of undoing or reprocessing any files 
or dependent files as provided in Applicant's specification and claims. 

Additionally, at paragraph 42 on page 14 of the current Office Action, the 
Examiner references that Smith modifies the teachings of Cohen and thus it would be 
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obvious to combine Smith with Cohen. However, the Examiner has not cited Cohen in 
the rejection of these claims (see e.g., paragraph 41), so the specific basis for combining 
Cohen is unclear. Applicant respectfully requests that the Examiner clarify the basis for 
rejection of claims 16 and 17 and, in particularly, whether the Examiner is relying on 
Cohen (as well as Lewis, Suzuki, Thompson, Battat and Smith) in making such rejection. 

For the reasons set forth above, Applicant respectfully submits that its claimed 
invention distinguishes over the combined references and overcomes the Section 103 
rejection. 

H. Seventh Section 103 Rejection: Lewis, Suzuki, Thompson and Schulze 
Claims 27 and 42 stand rejected under 35 U.S.C. 103(a) as being unpatentable 

over Lewis, Suzuki and Thompson (above) further in view of U.S. Published Application 
2006/0041493 of Schulze et al (hereinafter "Schulze"). Applicant's claims are believed to 
be allowable for at least the reasons described above pertaining to the deficiencies of 
Lewis, Suzuki and Thompson. Schulze does not cure these deficiencies as the referenced 
teachings of Schulze simply describe making a back-up file of downloaded identification 
data and routing codes and storing it in an off-site storage system. 

Additionally, at paragraph 45 on page 15 of the current Office Action, the 
Examiner references that Schultze modifies the teachings of Cohen and thus it would be 
obvious to combine Cohen with Schultze. However, the Examiner has not cited Cohen in 
the rejection of these claims (see e.g., paragraph 44 on page 15), so the specific basis for 
combining Cohen is unclear. Applicant respectfully requests that the Examiner clarify 
the basis for rejection of claims 27 and 42 and, in particular, whether the Examiner is 
relying on Cohen (as well as the other cited references) in making such rejection. 

Therefore, Applicant respectfully submits that its claimed invention distinguishes 
over the combined references and overcomes the Section 103 rejection. 

I. Eighth Section 103 Rejection: Cohen and Osborne 

Claims 32 and 47 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Cohen (above) in view of U.S. Published Application 2003/00120619 of Osborne et 
al (hereinafter "Osborne"). 
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Applicant respectfully requests the Examiner to clarify the basis of rejection of 
claims 32 and 47 given that the Examiner has not cited Cohen in the rejection of the 
independent claims (21 and 26) and other intervening claims on which claims 32 and 47 
depend. 

To the extent that the Examiner is relying on Cohen, Applicant's claims are 
believed to be allowable for at least the reasons described in Applicant's Amendment 
previously filed in this case pertaining to the deficiencies of Cohen. Osborne does not 
cure any of these deficiencies as Osborne describes a solution for remote monitoring and 
diagnosing of industrial equipment that seems to have little or no relation to Applicant's 
claimed invention for consolidation of financial information. Therefore, Applicant 
respectfully submits that its claimed invention distinguishes over the combined references 
and overcomes the Section 103 rejection. 

Any dependent claims not explicitly discussed are believed to be allowable by 
virtue of dependency from Applicant's independent claims, as discussed in detail above. 

Conclusion 

In view of the foregoing remarks and the amendment to the claims, it is believed 
that all claims are now in condition for allowance. Hence, it is respectfully requested that 
the application be passed to issue at an early date. 

If for any reason the Examiner feels that a telephone conference would in any way 
expedite prosecution of the subject application, the Examiner is invited to telephone the 
undersigned at 925 465 0361. 

Respectfully submitted, 

Date: January 8, 2010 /G. Mack Riddle/ 

G. Mack Riddle; Reg. No. 55,572 
Attorney of Record 

925 465 0361 
925-465-8143 FAX 
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